前面兩天，都是讓 AI 把故事說清楚，畫好邊界，然後希望它自己做完。如果等待沒有成本那肯定是挺好。

但現實是，手上從來不會只有一件事。

一個功能要上線，有人在寫程式、有人在 Review、還有Infra team在設環境。每個 Session 都跟我說「進行中」「等待中」，看板上每張卡也都乖乖待在某一欄。

好，那整件事到底卡在哪？還來得及嗎？

This is the question

PM 進不來，工程師沒興趣

這題通常會卡在兩種人中間。

PM 想知道誰在等誰，就得看懂 Gitflow - PR、Issue、分支、部署環境。跑去問工程師，拿到的多半是「快好了」「再等 Review」。輕飄飄地回答，但這會不會拖到上線？不知道。

工程師這邊也沒比較好。要徑法、浮時、甘特圖，教科書上都有。但要我們寫 code 寫到一半，停下來拆工作、估工期、前推後推算一輪？那會逼我們從程式語言的思考邏輯中脫離出來，切換思考維度很難，也太花時間了。大部分時候就是心裡大概排一下，然後開始寫。

兩邊都不是不想，是時間成本和知識落差擋在中間。PM 要補工程，要花很多時間；工程師要補專案管理，也要花很多時間。最後就變成各講各的，然後都覺得對方沒講清楚。

我後來想，這不就是 AI 最適合站的位置嗎？

Claude Code 看得懂 repo 裡的 PR 和 Issue，也知道要徑法怎麼算。讓它站在中間當翻譯，把工程現況翻成 PM 看得懂的圖，好像滿合理的。

不過光有 AI 還不夠，大家還需要一個都會去看的地方。我們團隊的答案是 GitHub 看板。

看板看得到卡在哪，看不到誰在等誰

我們有兩個 GitHub Projects 看板。

一個是給出貨看板，給 FAE、PD、業務看，他們手上沒有 repo，只想知道功能到哪一關了。另一個是敏捷看板，給工程自己用，放Object、Sprint、Epic、工作所需人天這些東西。

PM 本來就天天在看板上，工程師的 PR 和 Issue 也都掛在上面。所以看板很自然就成了兩邊的交會點。

但用久了你會發現一件事：看板看得到每張卡在哪一欄，但看不到卡跟卡之間誰在等誰。

「開發中」有五張卡，哪一張晚一天會拖到上線？「待辦」那張，是真的可以先放著，還是其實已經在擋別人了？

看板回答不了。這就是要徑法派上用場的地方。

要徑法，講到夠用就好

要徑法（Critical Path Method，CPM）其實只想回答一個問題：哪些工作一晚，整個專案就跟著晚？

做法是把每項工作畫成一個方塊，寫上工期和「要等誰做完」，然後算兩次：

• 上半部：每件事最早什麼時候要開始、做多久、哪時候能做完。
• 下半部：每件事最晚什麼時候要開始、做多久、哪時候能做完。

「最晚開始」減「最早開始」，就是浮時，也就是這件事還能拖幾天。

總有一條路徑，一天都拖不了那就是要徑。這條線上任何一件晚一天，上線就晚一天。

最後

reference: https://planyway.com/blog/critical-path-method-for-project-managers

原理大概就這樣。算的部分丟給 Claude 就好，我們要花力氣的是另一件事：跟它一起把工作拆對。

先讓看板可信

要徑圖的原料是看板。看板如果是舊的，算得再準也是白算。

所以我會先請 Claude 跑一次看板更新，幫我抓這幾種卡：

• 工程標成核心目標，出貨看板上卻找不到
• 已經標了版本，狀態還是「待辦」（這叫承諾，不叫紀錄）
• 已經進驗收關了，卻沒寫驗收步驟
• 卡片上的「現況」三週沒更新

這一步只回報，不動看板。要不要改、怎麼改，我們自己決定。

看板整理乾淨了，上面的負責人、狀態、工作大小、連到的 PR 和 Issue，才是真的能拿來算的東西。

從看板開口

我把這套流程包成一個 Skill，叫 flow-critical-path。開口只要講兩件事：範圍和終點。

/flow-critical-path 看板上「新網域登入」這組卡，終點是客戶能在正式環境使用

終點一定要講。「做完」可能是合併、可能是上測試環境，也可能是客戶真的用得到。終點不一樣，要算的工作就不一樣。

接著 Claude 會從看板上的卡出發，順著連結的 PR 和 Issue，整理出還沒做完的工作，每項列出名稱、負責人、要等誰，再估個工期。負責人和工作大小看板上本來就有，不用再問一次。

第一輪一定不準，這很正常

AI 看得到看板和 repo，但有很多事它看不到：

• 誰下週請假
• 採購卡在哪一關
• 某個 Reviewer 手上已經壓了三個 PR
• 某個決定，老闆其實還沒拍板

這些 PM 最清楚。所以第一輪清單出來，PM 要做的是改，不是從頭寫。

實際上大概是這樣聊的：

Claude：Review PR 估 1 天。
PM：他這週很滿，改 2 天吧。

Claude：看板上沒有「決定憑證方案」這張卡，憑證設定可以直接開始。
PM：不行啦，要先決定用哪種憑證，這個還在等主管。我去看板補一張卡。

這邊有個小習慣我滿堅持的：能改在看板上的，就改在看板上，不要只講在對話裡。

講在對話裡，只有這個 Session 知道。改在看板上，下次重算、其他 Session、其他同事，看到的都是同一份。

工程師這一輪也有事做：確認「要等誰」是真的。前端入口真的要等後端改完嗎？如果兩件事都是同一個人做，那就是一條線串下去，不能為了好看假裝可以平行。

你看，PM 補時間和人，工程師補技術上的先後，Claude 負責算。每個人只出自己最熟的那塊，誰都不用把對方的專業學完。

重點是，大家都在同一個平面，用同一個Skill，並更新這個Skill。

圖出來之後，才開始真正的溝通

有了圖，大家終於可以對著同一個東西問問題。否則都只是在雞同鴨講。

PM 會問：「Review 晚 3 天會怎樣？」

Claude 重算一次：Review 只有 2 天緩衝，晚 3 天，上線就晚 1 天。

「那主管下週才決定憑證呢？」

憑證決策有 3 天緩衝，晚 3 天還好，再晚就會拖到上線。

工程師會問：「我手上有三件事，先做哪個？」

「Review 還沒開始，要不要去催？」

以前這些問題要開會、翻 PR、在白板上畫半天。現在對著同一張圖問，每次都重算，答案都有數字。

這邊我跟 Claude 講得很清楚：讀看板、算要徑，你自己來；搬卡、改 Sprint，先問我。

讀跟算是同步現況，搬卡是規劃決定。這不就是上一篇在講的嗎？哪些事可以自己決定，哪些要回來找人。

踩過的坑：看板也是有額度的

我們自己採用的 GitHub 看板是透過 GraphQL API 讀寫的，每小時有額度。

我自己有一次在同一個 Session 裡一直重複讀兩個看板，直接把額度打爆，接下來一個小時所有看板指令全掛。更悲傷的是錯誤訊息還指錯方向，我一度以為是權限壞掉，查了好久。

後來 Skill 裡就多了幾條規矩：讀看板要有快取，同一次作業不要一直重讀；改多個欄位合成一次請求；搬多張卡用批次，不要一張一張搬。

如果你也想讓 AI 常常動看板，建議一開始就把這件事寫進去，會少走很多冤枉路。

我跟 Claude 約好的幾件事

為了讓這張圖值得相信，Skill 裡有幾條我不讓步的：

1. 要算，不要用看的。 要徑是前推後推算出來的，不是憑感覺畫箭頭。
2. 工期要寫明是估的。 直接寫在圖上，免得有人當成承諾。
3. 依賴照實畫。 同一個人連續做的事就是一條線，不要為了時程好看假裝平行。
4. 每件事都要有出處。 對得到看板上的卡、PR、Issue 或負責做決定的人，不能自己編。
5. 結論放最上面。 能不能動、卡在誰，一句話講完。

什麼時候不用畫？

一句話就能回答的，例如「這個 PR 是不是在等 Review？」，直接問就好。

只是想同步看板狀態，跑看板同步就夠了，也不用算要徑。

要徑圖真正好用的時候，是好幾條線同時在跑、人跟人之間互相等、而且有人開始問「還來得及嗎？」

最後

這篇想講的其實不是要徑法，而是這幾件事：

看板是 PM 跟工程師最自然的交會點，但它只看得到狀態，看不到誰在等誰。AI 可以站在中間，把看板上的卡算成一張要徑圖。人負責補 AI 看不到的東西，而且盡量補在看板上，讓下一次也用得到。

PM 不用學會看 code，工程師也不用把專案管理教科書讀完。

前兩篇讓 AI 知道「要做什麼」、「怎麼自己做完」。這一篇，是讓不同角色的人，終於可以看著同一張圖，聊同一件事。

附錄：精簡版 Skill

這是拿掉我們內部設定後的精簡版，放到 .claude/skills/critical-path/SKILL.md 就能用。看板編號跟欄位名稱要記得替換。這些都讓Claude處理就好。

---
name: critical-path
description: 把一組看板卡片、PR、Issue 算成要徑圖，找出要徑、每項工作的浮時、誰在等誰，以及最大的風險節點。當有人問「要徑」「什麼卡住了什麼」「還來得及嗎」「瓶頸在哪」時使用。只想同步看板狀態時不要用。
argument-hint: "<看板上的範圍> 終點是 <完成的定義>"
---

# Critical Path

先算，再畫。要徑一定要從往前推、往後推算出來，不能憑感覺畫箭頭。

## 步驟

1. **確認看板可信**
   - 用 `gh project item-list <看板編號> --owner <組織>` 讀卡片。
   - 先回報可疑的卡：已標版本卻仍是待辦、進了驗收關卻沒寫驗收步驟、現況超過 21 天沒更新。
   - 只回報，不修改。

2. **整理工作清單**
   - 從卡片出發，順著連結的 PR、Issue 找出所有未完成的工作。
   - 每項列出：名稱（動詞＋受詞）、負責人、工期（工作天，估計值）、前置工作。
   - 負責人和工作大小優先取看板欄位。
   - 同一個人連續做的事要畫成一條線，不能假裝平行。
   - 每項都要對應到真實的卡、PR、Issue 或決策負責人，不可自行編造。

3. **請人修正**
   - 把清單交給使用者，請 PM 補上工期、請假、等待中的決定，請工程師確認依賴。
   - 建議使用者把修正直接改在看板上，下次重算才用得到。

4. **計算**（第 0 天起算）
   - 往前推：`最早開始 = 所有前置工作的最早完成取最大值`；`最早完成 = 最早開始 + 工期`
   - 往後推：`最晚完成 = 所有後續工作的最晚開始取最小值`；`最晚開始 = 最晚完成 − 工期`
   - `浮時 = 最晚開始 − 最早開始`
   - 浮時為 0 的工作連起來就是要徑，長度就是總工期。

5. **找出風險節點**
   - 浮時少、而且被卡住或擱置的工作。
   - 附上一個能拿掉這個依賴的具體做法。

## 輸出

- 第一行：現在能不能動、第一個瓶頸是誰。
- 一張圖：每位負責人一條泳道，要徑標紅，風險節點標橘色虛線，工期註明為估計。
- 一張表：負責人、工期、最早、最晚、浮時、是否在要徑上。
- 風險節點與緩解做法。
- 使用者問「某項晚 N 天會怎樣」時，重算並回報總工期的變化。

## 界線

- 讀看板、計算、回報：可以自己做。
- 搬卡、改 Sprint、改欄位、貼到討論串：一定要先問使用者。
- 讀看板時避免重複全量讀取，GitHub GraphQL 有每小時額度。